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I. EXECUTIVE SUMMARY 


The purpose of this study effort is as follows: 

To expand the scope of the NASA End-to-End Data System (NEEDS) 
modeling effort to include a description of the scientists* 
functions in the data system. 

To design a model of the scientists' command and control activities. 

To develop a plan leadi;:g to validation of the model as part 
of the NEEDS command and control activity. 

In accoraplishing the ; tvv y, research was conducted into the command and 
control activities of the scientists for five space missions* The selected 
missions provided a representative spectrum of command and control systems 
employed by NASA for recent missions. Hie missions reviewed were 

International Ultraviolet Explorer (lUE) 

Solar Maximum Mission (SMM) 

International Sun-Earth Explorer (ISEE 1,2,3) 

High-Energy Astronomy Observatory 1 (HEAC 1) 

Atmospheric Explorer 5 (AE-E) 

The information gained by this review provided a basis for developing a 
generalized description of the scientists' activities. The description was 
found to be well represented by a secruence of activities. Because of this 
characteiTX 3 tic, it was decided that a series of flowcharts would be used to 
f convey this information. This set of flowcharts constitutes a model of the 

scientists' activities within the total data system. The model, which is 
presented in this paper, has been developed through three levels of detail. 

The first is general and provides a conceptual framework for discussing the 
system* The second identifies major functions and should provide a 
fundamental understanding of the scientists' command and control activities. 
The third level expands the major functions into a more detailed description. 
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For purposes of this study effort# the date system has been organized 
into three major subsystems (figure 1, following page 29) with conceptual 
boundaries between them. Ttie relationships (influences) among the subsystems 
are identified at the boundaries as conditions associated with the flow or 
movement of information and data products across the boundaries (data flows). 

Further refinements of the model are planned# leading to its implementation on 
a computer and validation as part of the command and control tasic. Future f 

efforts include the following: 

(a) Developing a mathimtatical model. Tliis effort will determine the * 

appropriate parameters associated with functional elements and the 
movement of information and data products. Ibe effort will develop 

both mathematical and statistical relationships which serve to 
relate the parauneters. 

(b) Installing and demonstrating the model on an appropriate computer. 

This effort will involve selecting an appropriate software pac)cage# 
and implementing and testing this package on the computer to ensure 
correct and effective operation. 

(c) Integrating the operational model with the remaining activities ir 
the command and control task. 

(d) Participating in the validation of the command and control model. 

t 

A successful Scientific User Modeled Subsystem for Command and Control t 

(SUMS) could make significant contributions in several areas of program 

f 

management. During a new mission definition phase, the use of the model could 
provide the information needed to assess resource requirements and system 
configuration, l^e model could assist in analyzing the impact of rn^jor data 
system changes on the scientific user. In addition# SUMS could be used to 
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obtain daily workload projactione for the autonomous scheduling systemi a 
major activity of the command and control task. 
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II. INTRODUCTION 


NASA's End-To-End Data System (NEEDS) effort is intended to provide a 
basis for transition into future flight projects by identifying and developing 
new technologies. This process is to be conducted in an orderly fashion, with 
systems research and analysis as one basis for prioritizing the various 
efforts. 

A. Objective 

The first objective of this effort is to expand the scope of the ongoing 
NEEDS Command and Control (C & C) modeling effort to include a description of 
the scientists' functions in the data system. The ongoing command and control 
study effort and the Resource Effective Data System (REDS) modeling activity 
for the end-to-end data system are integral parts of the NASA data system 
analysis activity. 

The second objective is to design a model for the scientifts' command 
and control activities. An understanding of the REDS model, as implemented on 
a computer, was obtained prior to commencing this activity so that maximum 
benefit frcxn the ongoing work could be obtained. 

The last objective is to develop a plan leading to validation of the 
model as part of the NEEDS command and control activity. 

The justification for modeling data systems arises from the realization 
that NASA'S budget is not likely to increase along with the technological 
ability to telemeter increased numbers of bits. When a future space project 
is conceived, an analysis of science objectives, the cost of data processing, 
delivery, storage, and data analysis ought to be performed. Data system 
models are the tools of choice for this purpose. 



B. Approach 


The approach taken to achieve the objectives was to 

1. Study a selection of recent missir :s focusing on the scientists* 
command and control functions- Five near-Earth missions were 
selected. Ihese missions are representative of NASA*s experience in 
active command and control operations. 1!hey are as follows: 

International Ultraviolet Explorer (lUE) 

Solar Maximum Mission (SMM) 

International Sun-Earth Explorer (ISEE 2, 3) 

High-Energy Astronomy Observatory 1 (HEAD 1) 

Atmospheric Explorer 5 (AE-E) 

The results of the study of the designated missions are contained in 
a companion report ^ "Information Base Used to Formulate the 
Scientific User Modeled Subsystem for Command and Control (SUMS)." 

2. Organize the gathered information in order to separate the 
scientists’ command and control activities. 

3. Evaluate the activities in order to assess the feasibility of 
including these functions in a data systems model. 

4. Develop a model concept which can adequately describe the functions 
experienced by the five missions studied. 

5. Extend the model to accommodate an incompletely specified data 
system, %#hich can easily incorporate changes as the data system 
design progresses. 

6. Present potential applications of the Command and Control System 
model. Included are applications to new flight projects, to 
automatic scheduling systems, and to major configurations of the 

data system. 

C. NEEDS Overview 

This overview is included for those readers with limited exposure to the 
NEEDS Program. NASA's End-to-End Data System (NEEDS) program is intended to 
identify, develop, and make available for its future ventures the critical 
technologies and analysis tools which otherwise %#ould not be accessible. A 
total data systems approach is taken, so that a proper cost-benefit assessment 
of each element of the system can be made. To this end, NEEDS-sponsored 
research is aimed not only at components which show potential for future 
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applications^ but also at analytical tools which can aid in the system's 
assessment* 

The NEEDS program has been structured into three phases. These phases 
and their objectives follow: 

Phase 2* Develop and demonstrate critical data syst«n components which 
will provide cost-effective sol*:.cions for several near-term, 
high data rate processing problems. 

Support systems analysis and planning for subsequent program 
phases. 

Phase 2 * Develop new systems concepts and identify and develop 

technologies which will enable significant improvement in 
information system performance and cost. 

Design, develop, and d«nonstrate advanced data subsystem 
technologies and techniques which when integrated into **ad-to- 
end systems will enable near real-time data management. 

Phase 2* Develop a mission capability for reliable handling and 

preprocessing of future space-acquired data (includes data 
storage, high-speed computer systems ^ and the capability for 
onboard fault tolerances). 

Provide a reduction in data access time and facilitate access 
to multiple data bases for multisource research by developing 
the architecture, protocols , and executive software for 
ground-based, high-rate, multiple-source data base management 
systems. 

Improve the performance of the command and control process 
while reducing labor-intensive costs by developing automated 
command generation capabilities and modeling and demonstrating 
command capability. 

Develop a system capability for cost-effective data system 
design and implementation ( including standard interfaces and 
protocols) and data analysis and develop system configuration 
options for the post 1990* s. 

The Phase 1 program element for GSFC empharis is the Resource Effective 
Data System (REDS). The GSFC objectives in regard to this element are to 
survey existing data handling systems and requirements, compile future mission 
and user requirwnents, develop system models, and test the effectiveness and 
efficiency of the system as new technology and techniques are introduced. 
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Phase 2 activities are grouped in the program elements listed below* 

Some areas of development do not directly involve GSFC* The objectives for 
each element are included* Actions in these areas are still in progress with 
most activity scheduled for completion in FY 82* 

Management/Systems Analysis 

provide management direction and coordination for entire program* 
Analyse program element technical perfonnance* 

Develop total system concepts* 

provide liaison with information systems design activities* 
Information Adaptive System 

Develoo and demonstrate a capability for adaptive control and 
processing of sensor data for onboard spacecraft application* 

Ancillary Data and Support Computing 

Develop concepts and ground demonstration hardware for providing 
onboard ancillary data (time, orbit, attitude) and associated ground 
validation and maintenance support* 

Modular Data Transport 

Develop and demonstrate concept and subsystems which will utilise a 
modular approach for data transport through the entire data system 
and a distributed architecture for spacecraft processing* 

Command and Control 

Define command and control system concepts which will reduce command 
response time and distribute control to the user community* 

Data Base Management 

Develop data base management techniques %#hich facilitate rapid, 
use-oriented interaction with large volume data bases. 

Develop an optical mass memory system design which provides large 
on-line storage capacity with high data transfer rates* 

Massively Parallel Processor 

Develop and tesonstrate a high-throughput computer capable of 
processing high-rate imagery data in real time. 
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The final structuring of the Phase 3 efforts is still being determined* T^e 
structure of the effort and identification of developmental tasks is expected 
to be finalized by the end of FY 81* 

D- Command and Control Overview 

This overview is included for those readers with limited exposure to the 

NEEDS program. Command and Control is identified within the HEEDS concept as 

one of the functional elements which compose the planned (generalized) NEEDS 

data system. Its description in NEEDS concept documentation is as follows; 

Command and Control (Ground) . Ihe ground command and control element 
provides the user a facility to process command requests. User command 
requests can be composed of command types such as real**time commands, 
group commands, stored commands (command^^ store" within the onboard 
command and control element for delayed execution) , and onboard command 
and control element program changes. User requests are received by the 
ground command and control element via the mission planning element. 

Command requests rt.ceived by the ground command and control are 
immediately processed for real--time command requests or stored within a 
data b/4se for group command requests and stored command requests for 
later execution. Command processing consists of command validation, 
command formatting, error coding, packet generation, and finally 
transmission and verification. Command conflict resolutions will be a 
function of the sequence design and integration process which prepares 
command sequences for transmissions. A file containing the conunand 
history is maintained by the ground command and control. 

This description includes many of the functions performed in what may be 
currently identified as the Payload Operations Control Center (POCC) and the 
Command Management Facility (CMF), if applicable to a specific mission. A 
discussion of the functions of the POCC aad the CMF is given in Api>endix B 
entitled Mission Support System. 

In addition, comnwind and control includes functions associated with the 
experimenters* facilities. In a general sense this facility supports tr.e 
users* (principal investigators teams, guest observers, etc.) requirements 
for interaction with satellite and supporting data. Idirough analysis of 
domlinked information, the scientist ascertains the need to change < command) 
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the statue of instrumentation in space. 

The examination of the scientist's command and control 
function/activities, described in this report will include the NEEDS concept 
functions identified as User and Data Bases (User) and those elements of 
Command and Control (Ground) appropriate to the scientist (user)* these 
functions are as follows: 

User * The user of the data performs information reduction/extraction 
operations on the received data* i>ata may be requested by the user via 
data queries* The user may operate the onboird sensor via the mission 
planning element and monitor its status* In general ^ the end-to-end 
nature of the system couples the user tightly to the sensor* 

Data Bases (User) * In general # these data bases are under conf^ol 
of the user, who schedules accesses and performs his own data base 
management* 

Experimenter Facility * The experimenter facility is the location 
where the user operates# receives and manages his data# performs 
any desired analysis and develops his command reques^f^/requirements 
to be placed on the data tystem* This facility may be centralized 
or distributed* 
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III. THE SCIENTIFIC USER SUBSYSTEM 


A. General 

The Scientific User Modeled Subsystem for Command and Control (SUMS) is 
to be a tool which can be useful for planning futxire satellite flight projects 
in addition to assisting in scheduling of telemetry acquisition. Tlie design 
is such that questions of increasing ccxnnlexity can be addressed, system 
optimizations done, and alternate configurations assessed. 'Wie greater the 
level of detail required, the greater the effort and resources required to use 
the model. 

The work reported here concentrates on functions associated with the 
scientific effort. Analysis of the spacecraft and ground data systems is 
progressing through other concurrent efforts under NEEDS Command and Control 
sponsorship. 

The command and control data system can be thought of as comprised of 
three major interrelated subsystems: the scientific user subsystem, the 

mission support subsystem, and the spacecraft/experiment platform subsystem as 
illustrated in figure 1. Concepts associated with the spacecraft platform and 
the mission support systems are contained in app>endices A and B. The 
scientific user subsystem is the major sxibject of this study. 

In developing the model, two sets of elements %#ere chosen to model the 
functions performed by the scientist and his supporting team and equipment. 

(1) The transformation set is comprised of elements with inputs, outputs, and 
algorithms which represent, to the chosen level of detail, the processes 
carried out within that portion of the data system. (2) The transportation 
set is comprised of elements which account for movement of information between 
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transformation elements, including delays and possible loss* Itie user model 
consists of these collections of elements and, in addition, a data flow 
management system* 

The functions performed by the scientist user system are presented at 
three levels of detail, l^ie third level, most detailed level included herein 
is not specific enough to contain the detailed hardware characteristics used 
in the researcher's wrk. While description to this level is possible, and 
for certain applications useful, developing the model to that level of detail 
is a logical extension of the concepts to be discussed, and it would be 
unnecessarily repetitious for the purpose of this report* The three levels 
tc be discussed are sufficiently generalized to acccxnmodate the five mission 
types included in this report. Consequently, when implemented on a computer, 
studies for optimization could be conducted for lUE, SMM, ISEE, AE, or HEAO 1 
types of satellite missions. The results could influence TDRSS and NASCOM 
loading, command and control procedures, spacecraft design, IPD loading, and 
the scientists* computational analysis capacity for future missions. Model 
extensions could be implemented to embrace additional future mission types. 

B. Model Application 

In the early phases of a data system design, little specific information 
about the project is known. However, NASA experience is relevant to new 
missions. Hie experience gained from some similar missions will permit the 
establishment of **rules of thumb. ** Hie combination of experience and specific 
choices for a future mission can be used for the model calculation. As the 
system design progresses, the rules can be replaced by the emerging design 
relations and design parameter values* The model, in other words, can become 
a special kind of archive for the experience gained through NASA's involvement 
in flight projeccs* Unlike conventional archives, application of the model 
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results in a computer tEsd automatic invocation of this accumulated knowledge* 
In order to place into perspective the role which SUMS could play in mission 
design and operations, the total NASA End-to-Knd command and control modeling 
activities will be reviewed* The NEEDS effort consists of study activities 
which analyee the mission support and science user subsystems* A future 
effort is planned which would integrate these new technologies into an 
operational data system for both mission design and automatic telemetry 
acquisition scheduling. The NEEDS command and control decomposition is 
described as consisting of three major subsystems which can be treated 
separately*^ A fully operational SUMS can play a key part in the 
model-assisted design of a future mission* In addition, once a mission 
concept is accepted, and the science investigations have been identified 
through the normal announcement and proposal process, SUMS could be used 
independently to assist the scientists in ground support and analysis systems 
design. This assistance could include projections of the requirement for 
shift operations at the users* facilities, and calculations of reserve system 
capacity requirements in order to achieve stated mission performance goals. 
For the operational mission, SUMS could be used to assess the impact of 
proposals for changes in telemetry acquisition and ground support services 


♦However, thw science objectives for a mission will influence the experiment 
platform alternatives. The available telemetry capacity within the mission 
support systsei will influence the telemetry rate choice alternatives. The 
projected budget situation will influence the degree to which a project can 
be an ambitious undertaking* And the resources anticipated for scientific 
analysis should determine the volume of data to be telemetered* NASA has been 
criticised for telemetering more data than it could afford to analyse. In the 
past, where exploratory missions were the rule and onboard selection and 
processing capacity was limited, this situation may have been justified. 
Because of the successful demonstrations offered by missions like SMM, 
preselection and preprocessing should now be considered by every project to 
control the volume of telemetered data* The cost of configuring a platform for 
onboard processing must be balanced against the cost of transmitting, storing, 
reducing, and analysing the telemetered bits. 
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on the scientific user subsystem. Ttiese assessments could be helpful for both 
day-to-day and emergency situations. 

C. Introduction to Detail Levels 

The Level 0 model (figure 1), the most generalised description of the 

system, is useful in defining and developing the concepts fundamental to the 

study effort, the basic idea of the boundary conditions (interrelationships) 

between the science effort and the remainder of the NASA data system, the 

interrelationships in a flowchart context, and the generalized boundary 

conditions of interest to this study effort. 

The Level 0 model groups the functions and activities of the command and 

control/data system into three categories: 

Scientific User includes the experimenters, their facilities, and the 
functions, activities and processing which occur under their control. 

Spacecraft/Experiment Platform includes all functions and activities 
performed on board the spacecraft. 

Mission Support System includes all ground-based functions and processing 
activities not specifically included in the science category. 

The data and operational requirements and other functional interrelationships 

that each category places on the other two are the boundary conditions of 

major interest in this study. 

At detail level 1, the model represents the major functions within the 
level 0 superstructure. This organizational framework provides a good 
intermediate level overview of the system operation and associated data and 
information flows. At level 1, each of the three level 0 categories 
(subsystems) is separately partitioned into major functional elements. At 
level 0, the entire data system is characterized as gross functional elements 
with generalized input and output parameters (boundary conditions) and 
transfer characteristics between the inputs and outputs. When a portion of 



the Bystem (one or more elements) is to be described in more detail, logically 
a level 0 element is replaced with a sequence of functions (elements) which 
more completely represent the transformation of input to output parameters in 
the format of a flowchart. Each of these level 1 elements has input and output 
parameters (boundary conditions) and transfer characteristics (algorithms) for 
processing input to output. Similarly, description of a portion of the system 
to level 2 amounts to replacing level 1 elements with more detailed sequences 
of elements. Each level 2 element has input and output parameters, and 
appropriate transformation functions. It is not necessary to define the 
entire data system to detail level 2 (or higher) in order to use portions 
of the model system at that detail level. The consequences are that details 
associated with the less completely specified portions are summarized at the 
more general level appropriate for the p^iTticular analysis being conducted. 
Such summarization would not reduce the validity of the analysis. 

D. The Basic Model 

The Level 0 model orc/anizes the NASA data system functions into three 
subsystems. These three categories are the sp^acecraft/experiment platform for 
all functions performed in space, the scientist user for command and control 
functions associated with obtaining data and the processing/analysis of the 
received data, and the mission support system for all ground-based functions 
not being performed in the scientist user category. These elements are 
illustrated in figure 1 (foldout at page 31). While these choices have 
consequences in terms of the perspective or focus of this effort, they are not 
unique; and alternate categories would serve as %#ell for overall data systems 
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Spacecraft/Experiment Platform^ Level 0 > In the development of this model/ no 

commitment to specific spacecraft design alternative is implied although 

mission specific functional requirements and/or performance specifications are 

addressed. Functions like the following are included: 

Measurement of scientific events to include the operation of the 
sensors and experiment instruments. Hie activities within this 
function will vary significantly from one mission to the next in such 
areas as type of events raeasured/data generated, the flexibility of 
the experiment system and the timely control and adjustment of 
experiment activity. 

Command handling to receive commands from the ground; distribute, 
either with or without temporary storage, to the appropriate 
functional process onboard the spacecraft; and to perform any control 
function for which programmed. 

Data handling to receive scientific information/ data from the 
measuring sensor/ instrument, temporary storage of data pending 
transmission to the ground; data processing within established 
capabilities and formatting of data into packets as required. 

Telemetry to transmit information/ data to the ground. 

Mission Support System, Level 0 . Hie mission support system, for the purposes 

of this discussion, is assumed to contain all the ground-based functional 

activities not included in SUMS. No commitment to design system alternatives 

is implied although some functional rec[uir«nents and/or performance criteria 

are included. Included within the mission support system model are functions 

like the following; 

Ground ccxnmunications necessary to tiansport data among the functional 
elements. This includes the STDN, NASCON, the network scheduling and 
operation and any other communications necessary to tie the data 
system together and provide the means for the required data flow. 

Systems management activities to ensure proper operation of the 
project. Hiis includes the appropriate project operations control 
center, command management/processing, and supporting ancillary 
functions. 

Data processing and handling activities necessary to receive data, 
handle the data, perform any required processing before the 
data/inf ormation is provided to the scientist user. This includes 
both quick-look and production data preparation for the "decom tapes" 
or "experimenter tapes" from IPD. 
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Scientific User^ Level 0* Included in this model are all resources associated 


with the experimenters' data processing, reduction, analysis, command and 
control, and scientific research* (One cannot treat the command and control 
system as separate from the research analysis system because the two are so 
tightly interdependent.) 

Functions like the following are included in this model: 

Developing thu commands desired and required to get the satellite*- 
borne scientific instrument to gather the scientific data. Ihis 
includes any necessary planning, scheduling, prioritization, 
consulting, and conflict resolvtion done by the science team. 

Responding to requests from functional elements within tlie mission 
support system for information, and/or interactions necessary for 
successful project operation and completion. 

Receiving, processing, and analyzing the scientific data initially 
acquired by the satellite instrument and processed/handled by the 
mission support system. This includes quick-look data, if 
appropriate, for feedback into the generation of commands for 
instrument operation as well as production data for final scientific 
analysis and use. 

Preparing reports. 

Preparing archival forms of the science data. 

Within the command and control system, the scientific user subsystem is the 
least quantifiable, and consequently the most difficult and controversial of 
the systems to analyze. Yet it is for the resulting science output that new 
scientific satellite missions are flo%m. 
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E. The First Expansion# Level 1 


In the level 1 model, the level 0 categories of functions are replaced 
with a greater level of detail. This controlled expansion represents major 
functional categories. Only the development of the Scientific User subsystem 
will be treated in this part of the paper. Ihe level 1 discussion of the 
spacecraft/experiment platform and the mission support system are contained in 
appendices A and B. 

Included in this level 1 system description for the scientist user model 

are the following major elements: 

Reception, Control and Distribution 
Analysis for Decisionmaking 
Planning and Coordinating Activities 
Decisionmaking 

Command Preparation and Forwarding 
Analysis of Production Data 
Development of Scientific Knowledge 

The interrelationships among these elements are shown in figure 2 (foldout as 
page 33). Discussion of transportation el«nents, shown as lines in the 
figure, is deferred to the "Interrelationship" discussion in section 4. 
Reception, Control and Distribution . Itiis function, as a separate element 
within the scientist area, is not always apparent. There are, however ^ a 
number of what might be considered routine administrative functions necessary 
to ensure efficient operations. This element accounts for the capability 
to receive incoming material, identify what it is and who it is for, control 
the distribution process and distribute the material to its intended 
receivers. If the incoming material is electronic data, the element would 
account for the necessary switching capability to a computer or an image 
reception device, as appropriate. 

Analysis for Decisionmaking . This element accounts for analysis %#hich leads 
to or supports the command and control decisions. Command and control related 
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analysis typically shares resources with science data reduction and analysis. 
Consequently, it is inevitable that coupling among these elements will occur. 
Also accounted for in this element would be any accompanying data storage. The 
incoming data, for this element, referred to as quick-look data, is processed 
as appropriate for the mission. Ihe processed data is evaluated for 
necessary completeness, and any additional data/information required is 
requested or otherwise obtained, l^e primary output is the results of the 
analysis which are furnished to the level 1 decisionmaking and 
planning/coordination elements. 

Planning and Coordinating Activities . Tliis element accounts for coordinating 
activities, meetings with other experimenters, and/or interactions with other 
organizations. Also included are provision for planning activities related to 
future endeavors. Hie results or outputs, in addition to the expected 
coordinated responses and programs, include revised plans and outgoing 
requests for information or actions by others. 

Decisionmaking . Committees of scientists use the results from analysis, 
coordination, and many other inputs to decide how to next configure/adjust an 
instrument or group of instruments. The decisionmaking element accounts for 
internal coordination and conflict resolution among the ccwnmittees. The 
output from this element consists of decisions for subsequent spacecraft or 
experiment configuration, operation, and control. 

Command Preparation and Forwarding . This element accounts for processing of 
command and control decisions. The amount of processing varies by mission and 
tends to complement elements within the mission support system. Decisions are 
converted to the necessary instrument commands or command requests. The 
commands or command requests may be tested and coded before being formatted 
for transmission or forwarding to the operations control center or other 
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network elements* Necessary documentation is also maintained in this element* 
Analysis of Production Data * this element accounts for the computer reduction 
and analysis of the input processed production data received from the 
Information Processing Division (IPD) or its equivalent* The data may be 
received as magnetic tape, images or other forms appropriate to the unique 
mission* Any additional information found to be required for complete 
analysis is obtained. Some of the results of this analysis may be fed back 
into decisionmaking. Ihe time frame associated with these processes is 
generally quite long, often as long as 2 years but sometimes as short as a few 
days. Reduced and analysed data are also forwarded for archived storage. 
Development of Scientific Knowledge . This element represents the culmination 
of the mission program* It accounts for resources consumed in investigations. 
Outputs include scientific papers, published documents, and presentations* 

F* The Second Expansion, Level 2 

At level 2, the model represents each of the level 1 elements in greater 
detail. Each level 1 function in the scientist user area is expanded to 
identify activities or subelements* This level 2 functional structure 
provides a foundation for comparing the command and control systems among 
various missions at a moderate level of detail* It also provides an 
organizational frame%#ork for structuring data flows throughout the system. 
Reception, Control and Distribution * This element is modeled as five separate 
activities or subelements. 

Identification . In this element, an examination is made of incoming data 

or material to determine the material type, the procedure for handling 

and the process for distribution within the system. 



Electronic Reception » Itiie element accounte for the electronic 


capability to hancUe incoming digital traneroitted data# directing it 
either to an appropriate ct^nputer or other processing device* 

Facsimile Reception * Ihis element accounts for the ability to record 
( receive) facsimile transmissions* 

Distribution * Ttiis element ensures that products, whether data or 
otherwise, are forwarded to the proper destination within the system* 

Storage * Itiis element accounts for the retention of data and information 

1 

volur.es. 

The interrelationship of these activities is shown in figure 3 (foldout at 
page 35). 

Analysis for Decisionma)cinq . Ttie subelements for this activity are as 
follows: 

Data Processing . T^is element accounts for the computer-supported 
processing of the data products. 

Storage . This element accounts for the capability to retain data and 
information volumes. 

Information Evaluation . T^iis element accounts for valiVation stepri, 

preliminary to analysis to ensure that all required data and information 

is present. If not, action is initiated to obtain requisite information 

or data. * 

Information Analysis . This element accounts for the examination, 

compilation and/or extraction of meaningful scientific information from 

the data and supporting information. 

The coupling of these elements is illustrated in figure 4 (foldout at 
page 37 ) • 
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Planning and Coordinating ActivitiM . Included subelementa are 


Coordination Requirement! * ’Wiia element accounts for the identification 
of situations and requirements that need coordination with othermission 
support personnel or other .scientific users; it includes requests for 
actions^ obtaining and processing the results. 

Meeting Preparation . *Ibis element accounts for the preparation and 
information gathering necessary before a coordination type meeting. 
Coordination Meetings , ^is element accounts for face-to-face discussion 
and teleconferencing for coordination activities. Ibese meetings may 
have a significant impact on the current and future decisionmaking and 
planning proces8<t^« 

Plans Developmon and Update . Ibis element accounts for the process of 
accepting the results of coordination activities, formulating new plans, 
merging results with other plans and developing revised plans. *!tie time 
required for completion of activities within the element varies 
significantly and will frequently be of sufficient length as to be a 
major delaying factor in identifying and implementing new (and improved) 
ideis, concepts and procedures. 

The coupling of these elements is illustrated in figure 5 ( foldout at 

page 39 ) • 

Decisionmaking . Ibe model subelements for this function follow: 

Information Examination , Ibis element accounts for the examination of 
information which leads to the decision process. Ibis element is similar 
to, and ar. extension of the normal analysis process. It provides for the 
review and comprehension of analysis results and other pertinent 
information so that command and control requirements may be generated. 
Decision Development . Ibis element is the point in the system where 
decisions for command and control requests ar« developed. In addition. 
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r^quiramenta and racommandationa ara brought togathar to influanca tha 


daciaiona appropriata for a apacific miaaicn and/or axparimant. 

Intarnal Coordinatioiu Ihia alainant accounta for tha aharing of 
objactivaa and achadulaa among tha varioua axparimantara participating 
in tha planning procaaa. Ml intaraatad acianca paraonnal (ox 
coaunittaaa) ara given an opportunity to contribute. 

Conflict Raaolution * TMa element accounta for management daciaiona 
which resolve any remaining conflicta pertaining to coroaumd and co;itrol 
after the committee procaaa ia concluded. 

The coupling of these aimanta ia illuatrated in figure 6 (foldout at 
page 41 ) • 

Command Preparation and Forwarding . TMa element includaa the following 
aube lament a: 

Command Development and Preparation . This element accounta for 
converting the command and control deciaiona/requeata from a qualitative 
type set of deciaiona into a format appropriate for command coding either 
by the scientific user or mission support personnel. 

Command Coding . Itiia element accounts for coding the command 
requirements into a format and language for testing hy computers (and the 
instrument control mechanisms). Coded commands are quality controlled to 
ensure accuracy. 

Command Verification -r.d Teat> ng . Ibis element accounts for verification 
and testing of the coded commands as required by the mission's data 
system. Ibis testing process# if used# is normally mission unique and 
may involve a spacecraft simulation package on a computer. 

Storage . This element accounta for the retention of data and information 
volumes. In this instance# a log of commands is among the information 
stored. 
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Cotumand Tran»mi««ion> 1tii» dlmsnt accounta for tht active procasa of 


•ending conuMinde and command requeete through the proper media (mail# 
computer link, phone call# etc.) to the miasion aupport ayatem. 

The coupling of theae functiona it illuatrated in figure 7 (foldcat at 
page 43 ) • 

Xnalyaia o f Production Data * The following aubelementa are included: 

Data Proceaainq * Thia element accounta for reduction and analyaia uaing 
a computer or other aui table alternative# 

Storage • Thia element accounta for the retention of data and information 
voluraea. It includea aervicea auch aa are available through# but not 
neceaaarily provided by# NSSDC. 

Information Evaluation # Ihia element accounta for the preliminary 
analyaia to enaure that data ia uaable and aufficiently complete to meet 
a particular atudy need# Inauf f icienciea are reaolved through 
acquiaition action. 

The coupling of these elementa ia illuatrated in figure 8 (foldout at 
page 45). 

Development of Scientific Knowledge # Thia element ia compriaed of the 
following aubelement and ia illuatrated in figure 9 (foldout at page 47) i 

Information Analyaia # Thia element mrcadritm for the thought# literature 
aearching# and other analyi^ia proceaaee aaaociated with the development 
of acientific knowledge. Included within ttie scope of thia element are 
computer-aaaiated work and reading proceasea# Not included are 
production or batch data processing (included in the previous element)# 
Information Integration . Thia element accounta for the merging of 
supporting or contradicting science information. 
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Scientific Reporting * This element accounts for the formulation of 
theories and the vrriting of reports. Included are the publication and 
distribution of scientific work in the form of oral seminars, literature, 
internal reports, etc* Also included are fxinctions like refereeing 
journal articles* 

New Proposal Preparation * This element accounts for preparation and 
submission of proposals for future research* Proposals can be for future 
flight experiments, for investigations with existing hardware (as with 
lUE), and for studies with data in national archives, etc* Also 
accounted for within this element are peer group committee activities, 
etc* 

A large fraction of the scientists* current and future resources ought to be 
committed to analysis, writing papers, speaking, and writing proposals for 
future work* Shifting more of the burden for future command and control 
activities to the scientists must be considered in balance with these 
activities. The objective of this "Development of Scientific Knowledge” 
expansion is to provide a basis in order to account for ( 1 ) the command and 
control burden on total science resources, and (2) the adequacy of science 
resources to analyze telemetered data. Further expansion would be necessary 
to account for details associated with kiiowledge generation* 


IV. INTERRELATIONSHIPS AND BOUNDARY CONDITIONS 


A. General 

In this section/ techniques for accommodating various levels of detail 
within the model and for substituting higher levels of detail for specific 
functional elements arc to be discussed. For purposes of presentation, the 
discussion will treat the interrelationships between the scientific user model 
and the mission support system model. This focus will not only serve to 
illustrate these concepts, but to provide a point of reference for planning 
purposes to those involved in the mission support system model development. 

Technique for Accommodating Detail Levels 

The example in figure 10 ( foldout at page 49) serves to illustrate the 
level 0 model, but with emphasis placed upon the interfaces among the model 
transformation elements. The four categories of both information and data 
which are exchanged between the scientific user and the mission support system 
are identified within the regioi. labeled boundary 1 in the figure. These 
categories represent the functional transportation elements of the level 0 
model for boundary 1. The corresponding category between the mission support 
system and the spacecraft/experiment platform subsystem is identified at 
boundary 2 in the figure. 

In figure 11 (foldout at page 51), the level 1 representation of the 
scientific user subsystem which was shown in figure 2 has replaced the SUMS 
level 0 bloc)c in the previous figure. (Also, only a portion of the level 0 
mission support system is shown.) As illustrated in this flowchart, commands 
and coiTiroand requests resulting from operations in the ** command preparation 
and forwarding** element are passed through the **command communications** 
transportation element. Arrival of commands in the network is accommodated by 
a forwarding process, indicated by the arrow, and a feedback process. 



labeled in the fiqure* (The forwarding and feedback functions are modeled 
by algorithms.) The information is fed back to SUMS through the **Coordination 
Communications** transportation element for distribution to the appropriate 
transformation elements within this subsystem* 

A completely defined set of transportation elements for the boundary 
between SUMS and the network depicts all communications between the 
subsystems. Developing a schedule for a mission is the equivalent of defining 
the total network load across a boundary for a mission. Thus, the link 
between different subsystem models is expected to occur through the 
development of appropriate schedules. 

In this example I the network was treate^^ at level 0, and SUMS was treated 
at level 1. Data and information transferred back into the level 1 ftubsystem 
were depicted within the lower level elaiuent through the use of algorithms. 

An appropriate algorithm was used for each communications path between the 
subsystems. (Similarly ;lthin SUMS, algorithms are used to represent the 
communications paths between inputs and outputs of the transformation 
elements. ) 

C. Technique for Substituting Levels of Detail 

In the example discussed in part B above, the model represented to 
level 0 was redefined to include a portion at level 1. TVo adjustments were 
made. First, a higher order element was replaced by a more detailed 
representation. Contained within this level 1 representation, is a more 
complete specification of the information and data which pass across the 
shared boundary. Itie second adjustment is made to the level 0 portion in 
order to accommodate this increased detail. Algorithms need to be supplied 
which account for feedback, transfer, and other processes that have direct 
bearing ujx>n the more detailed portion of the model. Substitutions and 



adjustments need to he made for each step in the evolutionary process of model 
development. However, this procedure is expected to become a matter of 
routine. 
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V. PERFORMING A CALCULATION WITH SUMS 


The flowcharts given in this report are one representation of the 
subsystem model* To use SUMS# significant effort in the form of model 
refinement# implementation on a computer# and testing must occur* Model 
refinement will consist of selecting from the infinite number of possibilities 
an appropriate set of input and output parameters for the elanents# then 
developing algorithms which relate the parameters* Tie algorithms will 
reflect the experience gleaned from this study's review of five missions. 
Implementation on a computer can ccxnmence when the model refinements are 
complete* Testing of the model will first show that SUMS represents current 
missions# followed by applications to future missions. Finally# the 
operational SUMS will be integrated with the other subsystem models to form a 
system model for command and control. 

It is premature to discuss the details of the elements# parameters# and 
algorithms. Nevertheless# it is possible to discuss calculations using SUMS. 
This is because the flowchart nature of the model composed of elements imposes 
constraints on the analytical techniques available for solution. 

Elements have the following characteristics; 

( 1 ) input parameter values 

(2) output parameter values 

(3) parameters which are neither input nor output# but are used in 
algorithms for the elonent 

(4) algorithms which relate parameters within the element 

(5) statistical variations accommodated in algorithms 

Consequently# SUMS will have a complex mathematical structure. Input 
parameters to one element are outputs from another. It is possible that some 
of these expressions may be transcendental in nature* Because of this 
structure# and the need to be able to substitute for selected portions of the 


system, an iterative solution for the desired parameters is the most likely 

ch'"»J ce* 

Such a calculation typically commences with an initialization step and 
proceeds by employing strategy to force a convergent solution* If the 
calculation is for a specific epoch (t) then a set of values 

(W 

will be determined. If the calculation is a simulation, then the result is a 
set of distribution functions for parameters 

(No predisposition for the functional representations {f(V)}, is implied. On 
the contrary, the resulting distribution functions are expected to be 
diagnostics for system design.) 

A simulation will probably be treated as a sequence of epoch 
calculations, where time is accounted for in a consistent way in all elements 
of the system. However, the precise formulation will result from the model 
refinement and implementation steps. 

A simulation provides a technique for testing both the sensitivity of the 
model data system to failures anticipated during nominal operations, and the 
sensitivity of the system to controlled changes in parameters. Simulations 
are, however, computationally expensive to run. Consequently, both 
simulations and epoch calculations have potential value for design and 
scheduling problems to be treated by SUMS. 
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Figure 1. The Basic Model (Level 0) 
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Figure 5. Planning and Coordinating Activities (SUMS Level 2) 
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Figure 6. Decisionmaking (SUMS Level 2) 








Figure 7. Command Preparation and Forwarding (SUMS Level 2) 
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Figure 8. Analysis of Production Data (SUMS Level 2) 
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Figure 9. Development of Scientific Knowledge (SUMS Level 2) 
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Figure 11. Boundary Channels (Level 1) 






APPENDIX A 


SPACECRAFT/EXPERIMENT PLATFORM 

Data sensing, data handling, and onboard processing, command and control 
of the spacecraft, data storing operations, preparation of telemetry, and 
communication services are accounted for within the spacecraft/ experiment 
platform portion of the data system. 

Most missions have three operational phases: 

Launch--the activities from lift-off until the end of powered 
flight in a preliminary Earth orbit. 

Acquisition — orbit and attitude maneuvers, spacecraft checkout, and 
experiment activation. Once powered flight has ended and the 
spacecraft has separated from the launch vehicle, the acquisition 
phase of maneuvers and testing begins. 

Mission Operations — carryinc out the normal activities for which 
the flight was intended, namely providing information about 
events as directed by the users. 

The launch phase is the most well-defined, and is normally carried out 
and controlled primarily by personnel concerned with the rocket launch vehicle 
and not involved with subsequent mission operations, 'ttie major impact which 
the launch phase imposes upon the performance of the NASA End-to-End Data 
System arises from the size and weight constraints resulting from the launch 
vehicle's capabilities. It has been expensive to launch sophisticated data 
processing equipment into space. Consequently, spacecraft have tended to be 
passive. Extensive computational and data handling support was required on 
the ground, not only to analyze the data, but to select the appropriate data 
for analysis. Recently solid-state technology has tremendously decreased the 
weight of data processing equipment. Also in the future, the Space Shuttle's 
increased payload capacity will allow the use of hardware that is heavier and 


more sophisticated than that which was previously used. For these reasons, 
the computational services provided on the spacecraft platform are expected to 
increase. 

Once the proper orbit or trajectory and attitude have been obtained, and 
the spacecraft and experiment hardware have been activated and tested, the 
mission operations phase — in which the spacecraft carries out its basic 

1 

purpose-—is initiated, ^acecraft control and user data handling/processing 
becomes (or should become) a routine process. The spacecraft performance 
discussion to follow is in the context of the mission operations phase. 

Size, weight, proven microcomputer technology, stand-alone ancillary data 
requirements, and the exploratory nature of the experiments are competing 
factors which limit the capability of the spacecraft to do more extensive 
onboard processing of experimental data. Major increases in onboard 
computational capacity will alter the spacecraft's capability to reduce the 
time and costs associated with ground-based computing support. The reduction 
is expected to occur from pre-selection of the data for analysis prior to 
telemetry. 

The major spacecraft platform elements are listed below. An onboard 
ccHnputer (data processor), if present, is considered as an integral 
capability. Ihe major functions are 

Command Handling . Commands are received and validated by the command I 

handling element. They can be executed in real time or stored and 

routed for execution at specified times. 'Wiis service is normally 

provided by command decoders and relay units. Sophisticated stored 

command programs and/or onboard computers, if used, will participate in ^ 

this process. 

Experiment Data Sensing, Handling and Processing . Ttiis element covers 
the sensing of information concerning the desired events as directed by 
user command. Sensor data is acquired, digitized, stored. 
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conditioned, validated, handled, and processed, and then transmitted 
to the ground via telemetry* 

Orbit System * Ibis element covers onboard orbit control activation 
(normally by ground command) and the generation of trac)cing signals for 
later orbit determination on the ground. Future types of navigation 
measur^nents will allow autonomous navigation to be performed onboard 
for computation and maintenance of precision position and velocity* 

Attitude System * *lbe attitude control and determination systems provide 
the capabilities to maintain stability and pointing control, to sense 
attitude information, and to provide attitude-related data. 

Cc^nnninications, Electrical, and Thermal Control * Ibis element provides 
spacecraft housekeeping services. Oommunications control directs the 
receipt of commands and transmission of telemetry, as well as internal 
data distribution. Electrical control provides spacecraft power 
generation, storage, and distribution between subsystem modules. 

Thermal control provides warming or cooling (along with appropriate 
monitoring capabilities) to maintain spacecraft components within 
acceptable temperature limits* 

Spacecraft Clock * Ibis element provides time signals to other functions. 
This clock is normally a regularly incrementing counter. In the future, 
an accurate GMT (or other similar absolute time) may be provided onboard 
using an autonomous spacecvaft clock* 

Telemetry Data Handling . This element covers telemetry commutation (i*e*, 
the process of sequentially sampled data sources in a repetitive manner) , 
encoding (the creation of the telemetry bit stream), storage, and 
transmission. Tbe future concept of data packetization may modify these 
procedures significantly. 

The model data flow is illustrated in figure A-1. Commands are received 
from the Spaceflight Tracking and Data Netwrk (STDN). Commands may be 
executed or stored for later access. Depending upon the tracking system type 
for a specific mission, a procedure is followed which results in orbit 
determination. 

Commands routed to the Experiment Data Sensing, Handling and Processing 
element enable the collection of information and detection of events as needed 
by the experiments. Experiment data is accumulated by the telemetry data 
handling element for transmission to the ground* Ibe attitude system; orbit 
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system; communications , electrical, and thermal control; and spacecraft clock 
functions are similarly directed by ground command. Appropriate monitoring 
data is then accumulated by the telemetry data handling element for later 
processing on the ground. 

The relationship of the spacecraft/experiment platform to the total 
system depends upon the data rates and the volume of telemetry from the 
satellite, and on the tradeoff between data processing onboard the spacecraft 
versus what must be later done on the ground. Other factors include the 
quality and reliability of the onboard hardware, and the characteristics of 
the spacecraft's orbit. 

The spacecraft/experiment platform functional activities (and any 
supporting computers) perform the following data services: 


Command Handling . Ttiis element receives all commands from the STDN, stores 

the commands (if appropriate), and sends commands to appropriate elements for 

execution (figure A-2). It includes the following: 

Receipt and Validation . Itiis subel^nent receives commands from the 
ground and compares them to allowable commands for validation. 
Primary verification is normally achieved by ground analysis of 
command memory dumps transmitted via tel«netry back to the ground. 

Command Storage . Tliis subelement stores commands that are not to be 
executed immediately. Stored commands are released for execution 
at a later time based on time computation or various sensor states. 

Decoding and Routing . Itiis subelement decodes and routes commands. 

Experiment Data Sensing, Handling and Processing . *rtiis element performs the 

primary scientific data gathering effort using unique scientific instruments 

(figure A-3). It includes: 

Sensor/Instrument . This subelement monitors, registers and/or 
gathers the raw scientific data and converts analog values into 
digital values. 
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Computer Control * Ttiie eubelement^ if ueed, accounts for the 
internal functioning of an experiment unique onboard 
computer/ processor* Using either stored coiwnand sequences and 
incoming commands ^ it manages the scientific data gathering effort* 

Instrument Control * Hiis subelement ensures that the various parts 
of the instrument are set/positioned in accordance with commands* 

Data Processing * Ihis subelement^ if an experiment unique computer 
is used, performs data editing, analysis and evaluation and, if the 
computer is so programmed, provides feedback to computer control for 
the conduct of experiments based upon some analysis of sensor data* 
The microprocessor can provide the capability to verify and select 
data* Also, experiment data packetization and compression is 
possible* 

Tape Recorder * This sv^element accounts for recording of data for 
later handling and inclusion into telemetry* 

Orbit System * This element (figure A-4) provides the following services: 

Sensing * This subelement generates a tracking signal for later 
ground orbit determination* The type of orbit tracking systcsm will 
vary by missions. 

Control * This subelment maneuvers the platform based on ground 
command * 

A ttitude System * This element (figure A-5) provides the following services: 

Attitude Sensing * This subelement senses the relationship of the 
spacecraft to the orientation of a reference vector (i.e.. Earth's 
magnetic field or unit vector in direction of the Sun, a star or the 
f:enter of the Earth). 

Attitude Determination . This subelement accounts for the 
calculation of the orientation relative to the inertial reference 
frame* 

Attitude Control Computation . This subeleraent generates appropriate 
control hardware commands to respond to computed requirements for 
reorie ng the spacecraft. 

Control Hardware Activation * This subelement activates attitude 
control hardware to change the spacecraft's orientation in response 
to health, power, stability, or other requirements. 


Cowmunlcationc , Electrical and Thermal Control. This element provide® the 


following housekeeping functions: 

Communications . *n>is subelement accounts for communications 
equipment and the system which transmits data from one location to 
another onboard the spacecraft and from the spacecraft to the 
ground. 

Electrical . Itiis subelement includes the electrical system for 
energy generation and power control to spacecraft subsystcsns^ 
instruments^ and payload. 

Thermal, l^is subelement includes the equipment and system to 
monitor heating^ cooling, and thermal control and to maintain all 
spacecraft components within acceptable limits. 

Spacecraft Clock . This element produces timing signals to drive onboard data 

acquisition, processing, and data transmission. The timing signal (number of 

time intervals) is furnished as input to other elements. Oommands may be 

received which result in adjustments in the time computation mechanism. 

Telemetry Data Handling . This element (figure A-6) includes the following: 

Telemetry Commutation . This subelemont sample^, the various 
instrument and spacecraft systems for data. 

Telemetry Storage . This subclement uses a tape recorder or other 
medium to store/collect telemetry data until the data can be 
transmitted to the ground. 

Transmission . This subelement sends data from the spacecraft to the 
ground station. 
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Figure A-4. Orbit System 
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Figure A-6. Telemetry Data Handling 






APPENDIX B 


MISSION SUPPORT SYSTEM 

The Mission Support System^ as used in this presentation, accounts 
for any portion of the NASA data system that is not included in either the 
spacecraft/experiment platform or the scientist user portions of the system. 
The generalized system described in this paper is appropriate to current 
missions* A. different set of details and system descriptions would be 
appropriate for a TDRSS-based ccxnmunications network and for future STS 
interfaces* l^ecific differences associated with unique missions will not be 
addressed. Some functions contained in this generalized description do not 
apply to some missions. Hiis generalized description will, however, provide 
suitable bases for discussion of mission differences. Ihe major functional 
components accounted for in the Mission Support System are listed below. 

Mission Operations Control 

Command Management 

Network Control and Scheduling 

Ground/Ground Communications 

Spacecraft/Ground Communications 

Data Capture, Editing and Decommutation 

Attitude Deterr Nation 

Orbit Determination 

Data Distribution 

Mission Operations Control . Payload Operations Control Centers (POCC) are 
concerned with the day-to-day operation and for the maintenance of the health 
and safety of the satellites, 'ffie activities required vary considerably, 
depending on the mission and design of the spacecraft. 


Inputs to the PCX^C include the following r 


Telemetry from the spacecraft via NASCOM 
Real-time commands from the mission operations staff 
Stored command loads from command management 
Onboard computer loads from spacecraft memory dumps 
Mission and network requirements for allocation of 
resources 

Outputs from the POCC include the following: 

Real-time commands to the spacecraft via NASCOM 
Processed telmetry to various users and for analysis 
within the POCC by the staff 
Displays for use within POCCs 

Weekly and daily schedules for handling satellite 
communications 

Control, requests, and schedules that drive the operation control function 
include the following: 

Pass schedule from the mission operations staff, as 
modified and approved by the Network Operations Control 
Center 

Ad hoc instructions from the mission operations staff 

Requests frv experimenters (direct or through the mission 
operations staff, depending on the satellite and the type 
of request) 


Real-time commands are those commands to be executed by the spacecraft as 
soon as they are received, as opposed to commands to be stored onboard for 
later execution. Real-time commands may go directly to the spacecraft (via 
NASCOM and a STDN station) or may be sent in advance to a ground station to 
be held for transmission during a subsequent pass of the designated 
spacecraft* Some missions may have permanent or semipermanent files of 
commands at ground stations from which appropriate commands can be sent upon 
direction from the POCC. 
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Activities performed include the following: 

Generating command sequences (calculating the spacecraft commands needed 
to perform a specified operation)* 

Setting up command bit patterns* In general, separate parts of the bit 
pattern are calculated or retrieved from data bases and combined into 
full commands in response to input mnemonics and other parameters* 

Checking for critical commands (identifying commands that could have a 
disastrous effect if executed under certain conditions)* 

Transmitting commands (sending them over NASCOM lines to a ground 
station) * 

Verifying receipt and execution of commands (checking telemetry to ensure 
that the commands were received by the spacecraft and the commands 
produce the expected results)* 

Command Management * This element provides a method for ccxnmunicating commands 
to the spacecraft* Considerations in selecting an uplink schedule include 
command syntax, power budgeting, sensor pointing, and intervals of high 
radiation dosage* Commands are converted or transformed from a format 
designed for recognition and use by personnel to a format designed for 
transmission over a data link for recognition and use by the spacecraft. In 
some cases, the command requests may be generated by an experimenter or 
spacecraft engineer in the spacecraft command language* Commands are combined 
to form a single command request list and merged into a single time-ordered 
master request list* Ittis master request list is divided into groups of 
commands called memory loads* A memory load is the largest number of commands 
which, according to certain constraints (e*g*, size of the onboard memory), 
can be sent during a station pass. The loads are then transmitted to the 
appropriate Payload Operations Control Center* 

Network Control and Scheduling * The Network Operations Control Center's two 
main functions are scheduling and operations* The scheduling group receives 
requests for mission support from the Payload Operations Control Centers and 


is responsible for maintenance time from ground stations in the STDN network 


Requests are merged under the constraints of resources and priorities to 
produce a conflicc-free schedule that will satisfy to the greatest extent 
possible user's mission support requirements. Weekly and daily schedules are 
issued. Schedule updates are also Issued to accomodate events that have been 
added or changed too late to be included in the daily schedule. These changes 
may occur as a result of situations like spacecraft emergencies, network 
changes, and priority changes. The schedules explicitly commit STDN and 
NASCOM resources and implicitly commit resources throughout the system. The 
operations group makes certain that all parts of the network--ground stations, 
NASCOM, and the operations control centers — are coordinated so as to support 
each scheduled event. 

Ground/Ground Communications - NASCOM . This element, the NASCOM network, 
functions as a "data conduit." In this context, NASCOM provides for the timely 
and dependable ground movement and transfer of data and commands between the 
spacecraft and mission control/support activities. NASCOM does not provide 
for any "processing" (transformation) of the data. Instead, it refers to the 
circuits, switching, and terminal facilities in a global system established 
and operated by NASA to provide longhaul operational communications support 
for all NASA projects. The system interconnects such facilities as NASA's 
foreign and domestic tracking and telemetry acquisition sites, launch areas, 
and mission and network control centers. NASCOM may connect with science data 
processing centers, experimenter or principal investigators locations, 
cooperating agencies of other U.S. or foreign government agencies, and 
spacecraft contractor's facilities. 

Tlte longhaul communications channels are, in most instances, full-period 
circuits or services obtained by lease from the various domestic and 



foreign carriers. Ttiese services include a variety of terrestrial cable, 
microwave relay, submerged cable, and communications satellite relay 
facilities. Ibe network is a global system with over 2.2 million circuit 
miles of diversely routed voice, low-speed data (teletype), high-speed data, 
and wide-band communications channels. It includes switching and technical 
control facilities linking approximately 100 terminal locations. Ibe netvrork 
provides all NASA mission control and network control centers with real-time 
communication access to spacecraft in flight. 

The NASCOM Network provides for 

Transfer of experiment and science data from ground stations to NASA 
processing centers. 

Transfer of spacecraft commands from control centers to the ground 
stations. 

Transfer of any other official communications between NASA facilities. 

Spacecraft/Ground Communications . Ibis element consists of the services 
associated with the transmission of data to the spacecraft and the receipt of 
data from the spacecraft. There are currently two major communications 
systems. Tbe larger and more complex system, the Spaceflight Tracking and 
Data Network (STDN), is managed from Goddard Space Flight Center (GSFC) and is 
designed to service near Earth spacecraft. Ibis category includes all 
Earth-orbiting and lunar spacecraft. Ibose spacecraft having interplanetary 
orbit or trajectories are serviced by the Deep Space Network (DSN), a global 
network of ground stations, operated by the Jet Propulsion Laboratory (JPL). 

The Satellite Tracking and Data Network (STDN) includes 14 ground 
stations. Tbe ground stations receive telemetry from the spacecraft, and 


provide tracking for orbit determination. Ibe ground station therefore serves 
as the primary link between the spacecraft and the project control centers, 
support activities and experimenters. 

Command lists are transmitted (uplinked) through the ground station from 
the Payload Operation Control Center (POCC) to the spacecraft* Telemetry data 
are received from the spacecraft and transmitted to processing activities 

> 

(POCC, experimenters facilities, IPD and/or others) via NASCOM and may consist 
of experiment data, attitude or orbit determination and control data, or . 

general spacecraft maintenance data. The main driver for ground station 
ictivities is the schedule of events received from the NOCC over the NASCOM 
network. These events include spacecraft passes, playbacks of data stored for 
future transmissions, retransmissions of previously garbled or lost data, and 
ground station maintenance periods. 

Data Capture , Editing and Decoinrau tat ion . Information processing of sensor data 
from the NASA unmanned science and application satellites is largely provided 
by GSFC*8 Information Processing Division (IPD). Sensor data to be processed 
can be classified into tvro categories depending upon their data rate: 
high-rate data (e.g., image data) and low-rate data. Accordingly they 
generally follow one of two major functional paths through IPD: the Image 

Processing Facility (IPF) and the Telemetry Online Processing System (TELOPS). 

r 

The Image Processing Facility performs digital image processing, 
conversion of data onto high-density tapes and selective preparation of 
digital and photographic products for the users. The IPD *8 image processing 
facility will accept the incoming image data and the definitive orbit and 
attitude information and perform some or all of the following: 
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analog-to-digital converaion, data foraatting, quality aaaasamant, 
daconpraaaion, radiometric and geometric correction, image framing, and 
editing and reformatting images in preparation for the final product. 

The primary outputs are high-density magnetic tapes and photographic 
(film) products. 

The Telemetry Online Processing System (TELOPS) involves the proper 

< 

receipt and capture of telemetry data; storage and retrieval of telemetry and 
I other related data, such as orbit and attitude data; and the processing of the 

data for distribution to the users in the form of digital tapes. The 
processing includes time analysis, editing, decommutation, ancillary 
attitude/eph«neris processing, and quick-look processing. The processed data 
then is placed on magnetic tape for storage and distribution to users. A 
centralized repository for these data is provided. 

Attitude Determination . This el«nent accounts for the process of computing 
the orientation of a spacecraft relative to an appropriate inertial or other 
reference frame. Attitude determination is based upon data gathered by 
several types of sensors on the spacecraft and requires sophisticated data 
processing procedures. 

The four major functional subelements of attitude determination follow: 
Attitude Control orients the spacecraft in a specified predetermined 
direction. This process of command generation, includes the generation 
9 of attitude changes (control. ) based upon current and desired attitude 

conditions. 

D efinitive Attitude Determination is the generation of an accurate 
attitude history perhaps weeks or months after the fact, as specified by 
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the definitive requiremente* Ihie information will generally be used 
by the end user in the analyaie of experiiAental data* 

Attitude Prediction provides forecast information on the spacecraft 
orientation by using dynamic models to extrapolate the attitude history. 

Real*>Time Attitude Determination uses incoming telemetry and orbit 
(epheroeris) data to compute attitudes within a short period of time after 

I 

receipt of the data. The computed parameters are normally displayed to 
allow the operations control center mon^ coring of spacecraft attitude 
and the performance of onboard attituc a control systems. Ihese computed 
attitude data are used to develop control commands designed to achieve or 
maintain a desired attitude. 

Orbit Determination . This element accounts for the process of providing 
trajectory and ephemeris support for spacecraft during launches, orbit 
maneuvers, and mission operations. Mission support operations include 
updating periodically (or as required) the orbital elements; generating 
ephemeris, acquisition, and scheduling data; and providing maneuver commands 
for orbit corrections. 

The two major inputs to the orbit determination and control function are 

(1) Trac)cing data from the STDN via NASCOM, and 

(2) Ephemeris data (previously generated). 

Other inputs include spacecraft conditions, attitude data, and approximate 
date and time for any maneuvers. ' 

The major outputs are ephemeris data (pairs of times and orbit vectors) ^ 

and new acquisition data. Other outputs include reports, scheduling and 
planning data, and maneuver commands. 

Data Distribution . This element accounts for the distribution of information 
and data products to the users. The distribution is done through one of three 
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major channels. Film products are handled within the Image processing 
facility and delivered directly to the users. Telemetry data products are 
forwarded to the tape staging and storage facility, where they are packaged 


and distributed to the t*i>ers 


(This facility can Involve NSSDC.) 
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